Since its release in 2002, the Microsoft .NET Framework has become one of the most popular frameworks targeted by developers of Microsoft Windows-based applications. This widespread prevalence ensures that code targeting the .NET Framework will be run in diverse environments by a wide variety of users. Many of those users, particularly at the enterprise level, may have special demands for customizations and enhancements that were not anticipated in the design of the .NET Framework and are not provided by components or platforms built on it. In many cases, third-party software products must meet such needs with hooking—a generic term for technologies that alter or augment the behavior of other software. Hooking is often accomplished by modifying existing code or modifying data structures that influence code execution.
In the execution environment of the .NET Framework, however, most code and data are essentially maintained as part of the internal state of the framework's application virtual machine. The virtual machine accepts platform-agnostic bytecode as input, and both the bytecode and the metadata that describes it are represented in a standardized format. Internally, the bytecode is passed to a just-in-time (JIT) compiler to be translated into platform-specific native code. The virtual machine maintains internal data structures that describe this native code, and both code and data are stored at dynamic locations in memory belonging to the virtual machine. In general, neither the native code nor the associated data is directly exposed to third-party code.
Most hooking solutions for the .NET Framework have focused on modifying bytecode rather than native code. Some solutions alter the bytecode of .NET executables (known as assemblies), either on disk before they are accessed or in memory at load time. Another common technique is to use the .NET profiling API to edit bytecode before it is JIT compiled and executed by the virtual machine for the first time.